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Herewith, a fairly old concept is published for the first time and named "Lucas Interpretation". This 
has been implemented in a prototype, which has been proved useful in educational practice and 
has gained academic relevance with an emerging generation of educational mathematics assistants 
(EM A) based on Computer Theorem Proving (CTP). 

Automated Theorem Proving (ATP), i.e. deduction, is the most reliable technology used to 
check user input. However ATP is inherently weak in automatically generating solutions for arbitrary 
problems in applied mathematics. This weakness is crucial for EMAs: when ATP checks user input 
as incorrect and the learner gets stuck then the system should be able to suggest possible next steps. 

The key idea of Lucas Interpretation is to compute the steps of a calculation following a pro- 
gram written in a novel CTP-based programming language, i.e. computation provides the next steps. 
User guidance is generated by combining deduction and computation: the latter is performed by a 
specific language interpreter, which works like a debugger and hands over control to the learner at 
breakpoints, i.e. tactics generating the steps of calculation. The interpreter also builds up logical 
contexts providing ATP with the data required for checking user input, thus combining computation 
and deduction. 

The paper describes the concepts underlying Lucas Interpretation so that open questions can 
adequately be addressed, and prerequisites for further work are provided. 



1 Introduction 

Motivated by planning for a large project on building educational math assistants (EMAs) at the state-of- 
the-art of computer mathematic^ Peter Luca^ supervised the essential design decisions for a "system 
that explains itself", which covers a major part of mathematics as taught to a major target group: solving 
problems in engineering and in applied sciences in academic courses and at high-schools. 

Two requirements were identified that are essential but conflicting: (1) design interaction and nota- 
tion as close as possible to what is written into textbooks during interactive tutoring and on blackboards 
during lectures and (2) implement software mechanisms as general and (logically) reliable as possible. 
The design tackled the conflict in several ways. They key idea is introduced as "Lucas-Interpretation" in 
this paper. Lucas-Interpretation operates on a novel kind of programming language based on Computer 
Theorem Proving (CTP). A program written in this language determines the next steps while the inter- 
preter builds up logical context providing automated theorem provers (ATP) with facts required to prove 
user input derivable or not. 



'MacSchubert http://www.iist.unu.edu/www/docs/annualreports/1993/main_7.html under founding director Dines Bj0rner 
^Peter Lucas was one of the pioneers in compiler construction and in formal methods 1161 1171 [Tsl . http://www.austria- 
lexikon.at/af/Wissenssammlungen/Biographien/Lucas_Peter 

P. QuaresmaandR.-LBack(Eds.);THedu'll ® ^ ^ , 

EPTCS 79, 2012, pp. 82-fToil doi: 10.4204/EPTCi:7931 ^'''''''1 . 

I 1 1 Creative Commons Attribution License. 
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Figure 1 : A coil witli a cross-sliaped kernel 

The design has been implemented in a prototype called ISACQ first the mathematics engine based 
on Isabelle |[26l . then a multi-user front-end based on Java-Swing. IS AC has been used successfully in 
high-schools |[22l l23l |25]| . Discussion of underlying concepts has started with focusing education at 
CADGME [245 and continued with focusing technology at THedu'll. The latter workshop confirmed 
the relevance and (still!) novelty of ISAC's conception. So, after ten years of implementation in IS AC, 
the underlying concepts herewith are published concisely first time. All concepts described in the paper 
appear appropriate in ISAC's implementation; not (yet) implemented features are explicitly designated 
as such. 

The paper is structured as follows: ^gives a detailed example which shall motivate the subsequent 
definitions, ^presents how ISAC uses deduction for checking user input, ^describes how computation 
is used to construct solutions of problems and ^introduces Lucas-Interpretation combining deduction 
and computation for automatic generation of user guidance. Open questions and related work are given 
ample space in ^ and finally ^gives a summary of Lucas-Interpretation and a conclusion for pedagogy. 

2 Running Example 

In order to illustrate the design principles, one example will be used throughout the paper. This ex- 
ample is from a problem-class with strong traditions in German speaking countries called 'Extremwert 
Aufgaben'. The example's complexity is at an intermediate level between high school and university, 
thus indicating the concepts' usability from early introduction of variables up to mathematics applied in 
studies of science and of engineering. 

Example problem: Given a circle with radius r, where two rectangles with length u and width v each 
are inscribed as shown in Fig^ This figure shows the section through a coil; the induction current is 
proportional to the area of the cross-shaped kernel of the coil. Determine u and v such that the kernel's 
area A is a maximum. 

Traditionally the problem-class 'Extremwert Aufgaben' is taught in calculus courses, thus specifica- 
tion takes geometric considerations 'as obvious' and immediately comes to algebraic formulas as used in 
the problem's formal specification below. The running example has at least two different specifications: 

Specification no. 1 : 
input : { } 
precond : < r 



ISAC stands for /5Abelle for Calculations in Applied Mathematics, http://www.ist.tugraz.at/projects/isac 
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output : { max A, u,v} 

postcond : A = 2mv - A (|)2 + (i)2^^2^ 

VA' u' v'. (A' = 2u'v' - (u'f A + (^)2 = r2) ^ A' < A 
props : {A = 2mv-m2, (f)2 + (|)2==r2} 

Field tests showed, that learners understand what to input in the fields 'input', 'output' and 'props'; 
the proper postcondition in field 'postcond' , however, is out of scope for most students of the target group. 
The first two fields, 'input' and 'output', are standard, the last one is additional: the field 'props' contains 
elements of 'postcond', and although the "logical part" (V,3. =^,A) is dropped, 'props' distinguishes 
problems nicely; in fact, the second specification of the running example differs characteristically in 
'props', not only in 'postcond': 
Specification no. 2: 

input : { } 

precond : < r 

output : { max A, u,v} 

postcond : A = 2uv-u^ A 3a. (5 — rsina A 5 = rcosa) A 

VA'm'v'.(A' =2mV-(m')^ a 3a'. = rsina' A ^ = rcosa')) <^ 
props : { A = luv — u^, | = rsina, 5 = rcos a } 

In these two examples the fields 'postcond' have the same structure; without having this implemented 
in ISAC yet, we expect that postcondition can be generated automatically from the equations in 'props' 
and a pattern of the postcondition's structure for the respective problem class. The following definition 
is (almost) standard. 

Definition 1 (Specification) A quintuple {I , p(I) , O , q{I , O) , r{I , O ,A)) is called a specification where I 
is a set of variables (the input variables), p{I) is a formula in which only the variables from I occur 
freely (the precondition), O is a set of variables (the output variables) such that I HO = {}, q{I, O) is a 
formula in which only the variables from lUO occur freely (the postcondition) and r{1, 0,A) is a set of 
elements of q{I^ O) without quantifiers such that 

V/, O. p{I) [qil, O) 3A.r{1, 0,A)) 

is called properties. A vector of terms S{I) in which only I occurs freely (the solutions) solves the 
specified problem, if the following holds: 

V/. p{i) ^yo.o = S{I) =^ q{I, O) 

The specification's elements /,/?(/), 0,^(7, 0),r(/,0, A) are labeled by 'input', 'precond', 'output', 
'props' respectively in the two above example specifications. A in 'props' contains the variables which 
were existentially bound in q{I, O). 

Given a specification as an implicit definition of output values, a calculation is a transformation to an 
explicit definition by stepwise construction of output values. For instance, give specification no.2 from 
above, a calculation might be given by the steps in lines #01.. #20 below. The calculation as shown below 
is the result of various experiments trying to accomplish the two conflicting requirements mentioned in 
the introduction, (1) traditional notation and (2) reliable mechanized treatment. 

The details of the calculation below created by ISAC will be explained later together with the mecha- 
nisms which create the steps and which check the steps if input by the learner. Reactions of students and 
teachers to this format suggest to just explain what lists like [maximum J?y, calculus] or [make, diffable, 
function] mean: In ISAC the question for the lists is answered interactively by following a link exactly 
to the respective specification. Here on paper a link to all specifications in ISAC is giveirl 



^http://www.ist.tugraz.at/projects/isac/www/kbase/pbl/index_pbl.html 
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01 • Problem [maximum Jby, calculus] 

02 1-A = 2- m- v-m2 

03 • Problem [make, dijf able, function] — 

04 ... A(a) = 8 • • sina -cosa • (sina)^ — 

05 • Problem [onJnterval, max, argument] 

06 h A(a) = 8 • • sina -cosa -4- • (sina)'^ 

Subproblem [differentiate, function] 

07 • Problem [differentiate, function] 

Apply _Method Differentiate 
Take ■ r^ ■ sina ■ cosa - 4 - r^ ■ {sina)^) 

08 h ^(8-r^-sina-cosa-4-r2- (sina)^) 

Rewrite £{a- u- b-v) = a- £u- b- £v 

09 = 8-r^- ^(sina-cosa)-4-r2- ^(sina)^ 

Rewrite ^(«- = <5^+ S« " ^ 

10 = 8- • (sina- ^cosa + (^sina) -cosa) -4-r2 • ^(sina)^ 

I^ewrite i{u")=n-u"-''£u 

11 = 8- r^- (sina- ^cosa + (^sina) -cosa) -4-r^-2- (sina)^ ^^sina 

12 = : 

13 = 8-r^-(-(sina)^ + (cosa)^-2-sina-cosa) 

Check_Postcond [differentiate, function] 

14 ... A'{a) = S-r^-{-{sma)^) + {cosa)^-2-sma-cosa) — 

15 • Problem [onJnterval, goniometric, equation] 

16 ... a = tan-i(-l + V2) 

Check_Postcond /^onJnierva/, max, argument] 

17 ... a = tan- 1 (-1+72) 

18 • PTohlem [find-values, tool] 

19 ... [u = 0.23-r,v = 0.76-r] 

20 ... [u = 0.23-r,v = 0.76-r] 

The numbers on the left margin above do not belong to the calculation, they are for reference in this 
paper. The strengths of the above format come to bear on interactive worksheets, for instance, the • 
paired with . . . (on the same level of indentation) indicate places where intermediate steps are collapsed 
(as in lines #03.. #04) or can be unfolded (as in lines #07.. #14) — collapsed or unfolded on request by the 
learner, whether requiring a survey (collapsing and getting the big picture) or whether requiring details 
(unfolding and pushing parts out of the screen which are not relevant at the moment). 

Calculations show two kinds of elements, formulas and tactics. Formulas are shifted to the left 
margin, which are indented according to a tree structure. Tactics are shifted to the right margin. In the 
above calculation the tactics are Subproblem, Apply_Method, Take, Rewrite and Check_Postcond; 
the others are not shown ( — ), according to the tradition to omit on blackboards whatever is not relevant 
at the moment. 

So, the above calculation for the running example provides a first impression, which will motivate 
rigorous treatment and formal definitions in the sequel. 

3 Deduction for Checking User Input 

The present prototype checks formulas input by proving equivalence modulo a specified algebraic theory, 
that means by rewriting to normal forms and checking respective equality. For instance, acceptable inputs 
at line #12 in the above calculation would be those at #12 (a...z) below: 
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11 8 • • (sin a • ^cosa + sina) - cosa) — 4 - - 2 • (sina)^^' • ^ sina 

12(a) = 8 • • (sina • (— sina) +cosa -cosa) — 4- -2 • (sina)^"^ • ^ sina 

or(b) = 8 • • (sina ~cosa + sina) -cosa) — 4- -2 • (sina)' -cosa 

or(..) = ... 

or(z) = 8 • • (-(sina)2) + (cosa)2 -2- sina -cosa) 

Each of the inputs (a...z) has (z) as a normal fomj^ so each of the inputs is equivalent modulo the 

simplifier. Although relying on Isabelle |26| as much as possible, IS AC initially implemented a rewrite 



engine of it's own in order to meet the requirement of transparent single-stepping discussed in j: 3.1 
Since there are plans to provide Isabelle's simplifier with appropriate features of transparenc)]^ ISAC 
has implemented Isabelle's proof contexts [30 1 recently in order to re-use Isabelle's simplifiers. 

In Isabelle a proof context is created from an Isabelle theory, i.e. initially it contains all the facts 
from that theory, and then it is extended dynamicall with facts encountered during interactive proof con- 
struction. Isabelle's proof language Isar 1211 is block-structured and proof contexts follow this structure. 
So proof contexts contain all locally generated and modified facts for calling Isabelle's ATP tools, one 
of which is the simplifier. 

ISAC will re-use the mechanism of Isabelle's proof contexts in order to not only use Isabelle's sim- 
plifier, but also Isabelle's other ATP tools. So we claim for a judgment like 

F^.f (1) 

where F is the sequence of formulas already present in a calculation, / is a newly input formula and x is 
a context providing all facts required to derive / via an ATP tool (l-). F and / are the formulas visible in 
the calculation, x are the invisible facts additionally required for mechanical proof. §5.2|shows, how x is 



generated step by step for the calculation of the running example on p 85 



3.1 Steps in Derivations 

Experience from educational practice indicates a specific requirement on judgments from ATP: judg- 
ments shall be presented with comprehensible intermediate steps. This requirement is hard for ATP, 
often relying on tools like tableau provers, SMT solvers, on sequent calculi etc., which employ abstract 
representations hardly understood by novices. However, in case ATP involves simplification (which 
is frequently the case) this requirement can be successfully accomplished by grouping the rules and 
showing the rewrites of the groups (and postpone further details to further inquiry). The issue has been 
acknowledged by CTP development and it seems worth the effort for educational reasons: 

When novices are in the phase of acquiring confidence in an EMA, then their curiosity should be 
decisively supported and questions answered; otherwise EMAs reinforce the wide spread impression 
of mathematics as magic which cannot be understood. So EMAs should be "transparent" to learners' 
inquiries any time and respond with comprehensible intermediate steps. 

The requirement for steps coincides with the practical requirement to have some means to stepwise 



construct a calculation; these means are tactics as shown (partially) in the example calculation on p 85 



^Algebraic equivalence modulo thy of these variants of / is not decidable in general, since there is no normal form for terms 
containing trigonometric functions |4|; however, in the above case and in most other cases the class of terms is restricted such 
that ATP reliably can reject or accept an input. 

^http://isabelle.in.tum.de/gsoc-ideas.html#simptrace 

^Every few weeks the Isabelle mailing list receives a request by a novice for intermediate steps. A "visual tracing facility 
for the rewriting engine" is already addressed at http://isabelle.in.tum.de/gsoc-ideas.html. A related feature exists already in 
"proof reconstruction": data returned from ATP are inserted into Isar proofs in a human readable manner. 
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Since formulas in a calculation do not contain all information required for mechanical treatment, and this 
information is contained in contexts, tactics need to operate on contexts. So we have two kinds of tactics. 



(1) those introduced in the example calculation on p 85 and (2) those explicitly operating on contexts; 
there is a one-to-one correspondence between (1) and (2), so we need not distinguish between them, 
except in rare cases: then (1) will be called external tactics and (2) will be called internal tactics. 

Contexts contain the preconditions p{I) of a specification, the type-constraints given by the input 
variables / and output variables O, assumptions generated and used by conditional rewriting etc. All 
these facts decide whether a tactic is applicable or not. 

Applicability need to be defined for each tactic separately. With respect to the running example on 
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tactic Rewrite applied at #08 requires the fact, that A(a) is differentiable, and also the left-hand 
side of the theorem j^{a-u — b-v)=a--j^u — b- j^v must match a redex in the respective formula. Tactic 
Subproblem [tool, findjvalues] is applicable, if the input variables of the respective specification have 
been generated in the calculation already, and if the precondition holds. There are also more complicated 
tactics, for instance handling case-distinctions, which do not show up in the running example. The 
following definition seems straight forward. 

Definition 2 (Step of calculation) Given a specification s = {I,p{I),0,q{I,0),r{I,0,A)), a sequence 
F of formulas, a formula f, contexts x andx' and a tactic t, then a step is described by the rule 

t is -applicable Jn {x,F) x'^x' F hx x' F /' 
x,F^' x',F®f' 

where F ® f means insertion of f into F at a position according to t. The rule is applied to the initial 
configuration xq^Fq with tactic tg, were xq = p{I) Ua;^^^^^ ^) Ux^/,y, i.e. xq consists of the precondition, 
the type constraints Xty,pes[i,o) <^>^d the context Xfhy initialized by theory thy, Fq = and to is either Take 
or Subproblem. 

Tactics are designed functional such that for allt,x,F there exists exactly one x' , F' such that x, F — 
x' ,F'. So we can say t applied Jo (x,F) = (x',F') 

This definition does not tell whether a step is triggered by input of formula /, by input of a tac- 
tic t or something else. Although steps are functional, calculations generated by these steps are non- 
deterministic, because there may be many tactics applicable at one and the same configuration; this vari- 
ability of calculations is the challenge for learners when deciding on the next step of calculation, ^will 
tell details about input of formulas and/or tactics after some further prerequisites have been introduced. 

First follows a definition of calculation. The above approach taken via steps suggests in operational 
view according to [i28il : 

Definitions (Calculation) Given a specification s = {I,p{I),0,q{I,0),r{I,0,A)), then a calculation is 
a labeled terminal transition system c = {X , ,^{F),T ^,S), where the set of configurations isX x £P{F), 
X a set of contexts and ^{F) a set of sequences F of formulas, the actions t £T are called tactics, the 
transitions in — t-' (1 {X x ^(F)) x T x {X x ^(F)) are the steps of calculation introduced in DeJ^ 
The terminal configurations in set S C X x ^(F) are called solutions ofc. 

Further details on solutions are given in j]3.2| 



Summarizing, a calculation consists of steps each of which is derived from the steps previously 
constructed; derivation of the steps relies on logical facts (in contexts x) not shown to the learner without 
request. The internal machinery handling the contexts x will be introduced in the subsequent sections. 
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3.2 Checking Solutions of Problems 

This subsection presents the only part of the introduced concepts, wliich is not yet implemented in ISAC. 
This part raises open questions, but is essential for "a system which explains itself": such a system should 
not only construct a calculation stepwise as described in the previous section, such a system also should 
show that the result of the calculation is a solution of the specified problem. This means (in analogy to 
judgment ([T]) on p 86 1 we want to have a judgment 



Fh,q{I,0) (2) 

where F are the formulas in the (completed) calculation, x is the final context and q{I, O) is the postcon- 
dition on the input / and the output O in the respective specification. 

A look at the running example sheds light on the challenges for designing the details for an imple- 
mentation of In the example /?(/, O) is 

postcond : A = 2uv — u^ A 3a. (| = rsina A j = rcosa) A 

VA'm'v'.(A' = 2m'v'-(m')^ a 3a'. = rsina' A ^ = rcos a')) ^ A' < A 

The postcondition's 3 is accomplished by constructing a in the calculation's lines #15-#16. A com- 
plete proof would have to re-curse to the postcondition of (Sub-)Probleni [onJnterval, max, argument] 
at line #05 which might look like 

Va. a G ]0,|[^A(a) < A(tan"i(-1 +\/2)) 

A closer look suggests to have not only this postcondition in the context x, but also the function A(a), 
the facts A = A(tan^^(— 1 + \/2)), u = 0.23, v = 0.76 etc. — so (automatically!) proving the final 
postcondition needs to rely on a well-stocked context x; building x is the main concern of ^ 

Since we have introduced a calculation as "consisting of steps each of which is derived from the 
previous steps" the steps need to be considered. The final step in the example calculation is in line #19, 
obtaining the values [u = 0.23 • r, v = 0.76 • r7 as results of (Sub-)Probleni [tool, findjvalues]. These 
values are approximations of exact terms which are too large to be carried through a calculation by 
hand; due to the design decision for notation "as close to what is written to traditional blackboards as 
possible" the running example also uses approximate values — however, approximate values cannot 
prove the postcondition given above; the postcondition would require re-formulation by using the notion 
of "approximation errors", which would make the postcondition and the proof even more complicated. 

An implementation for checking solutions shall be analogous to Def J2] on stepwise construction of 
calculations, i.e. there should be a final step which completes the calculation such that the postcondition 
holds: 

Definition 4 (Result of calculation) Given a specification s = {I,p{I),0,q{I,0),r{I,0,A)) and a cal- 
culation c = {X , ^(F),T,^,S) as a labeled terminal transition system with transitions according to 
DeJ^or steps of calculation with xo,® ■ ■ ■ — x„,Fn _ ^Check_Postcond x^^Fn such that 

and for every variable o G O there is an equation o = r in Fn such that all the equations can be ordered 
in a sequence 

o\ =ri,02 = r2,...,On = r„ 

where every Oi does not occur in ri , . . . , r,-. Then r^,. . . ,r„ is called a result of c and x„ , F„ is called a 
solution constructed by c. We also say that calculation 'c isxompleted-with (xn,Fn) '. 
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Figure 2: A calculation is a side-effect of a functional program 

4 Computation for Constructing Solutions 

Since computers exist, they are used to compute some output from some input, where the resulting output 
fulfills certain expectations — i.e. they are used just for the purpose formalized in the above Defj4]for 
solutions of computations. Symbolic computation allows to handle formal objects of arbitrary level of 
abstraction, even real numbers like tan^^(— 1 + ^/2) infinite computers {^/2 etc. not as a floating point 
number, of course). 

Computation envisaged in this section is used to create steps of calculations. ISAC's design provides 
a functional programming language for doing that computation; given the characteristic of functional 
programs to produce a result (without intermediate states), the question arises, how intermediate steps 
can be created such that interaction on these steps is possible (since this clearly requires states related 
to these steps). Fig|2]on p 89 gives a preliminary answer to this question: the calculation and respective 



steps are created as a side-effect of interpreting the program; the states and interaction on the steps of 
calculation are handled by the interpreter of the program. The role of a dialog in such an architecture 
seems natural, but details are out of scope in this paper. 

4.1 CAS-like Functionality in Programming Languages 

For constructing calculations we need functionality well-known from Computer Algebra Systems (CAS): 
for instance, differentiation and equation solving in the running example on pj85] Indeed, CAS-based 
programming languages [ L 2QJ are most successful in software production for engineering and science. 
However, CAS-based languages do not commend themselves for educational math assistants — users of 
CAS are responsible for when to apply CAS functions and for how to use their results; so learners might 
be over-challenged by such responsibility: equation solvers might have lost some solutions, simplifica- 

2 1 

tion might imply partiality conditions without mentioning them (e.g. = x+l without mentioning 
Xy^ I) etc. For education we want to have systems "which never make mistakes" |[T2l . 

Deduction is already in the game since ^ so we advocate rigor corresponding to CTP: we claim 
any CAS -function to be accompanied by an explicit formal specification. Coming back to the running 



example, differentiation as shown for the example calculation in lines #07.. #13 on p 85 is specified by 



Specification of Problem [differentiate, function ]: 



input 
precond 
output 
postcond 



A V. / is jdifferentiable 
{f, range) 

Vv. V e range (A v. f ){v) = lim,,^o (^''■/)(^'+^)-(^"-/)(") 



and this implicit specification is transformed to an explicit specification, i.e. a calculation, by the tactic 
Subproblem [differentiate, function]: in line #07 this tactic starts the Sub-Problem [differentiate, func- 



90 



Automated Generation of User Guidance 



tion] and solves the problem by tactic Apply .Method Differentiate. The respective program is shown on 
p 92 below. 

The above requirements advocate a novel kind of programming called "CTP-based". Considerable 



work is already done preparing such languages iT2l[T3l[T4il : this is discussed under related work in j: 6.3 



4.2 A CTP-based Prototype Language 

ISAC implements a programming language, which is appropriate for describing mathematics found in 



problems of engineering and of science. The following program generates the calculation on p 85 for 
the running example; at a first glance the reader sees a purely functional program with the usual key- 
words LET.. IN, IF.. THEM.. ELSE; at this point the only difference are the function calls: identified by 
Subproblem, these calls are associated with a theory (e.g. Reals), a reference to a specification (e.g. 
[make, diffable, function] and a reference to the function itself (e.g. makejun). 

In the same way the Subproblems are accompanied by theory, specification and program, the exam- 
ple program below is accompanied by a theory and a specification already introduced in two variants (for 
the same program!) no. 1 or no. 2 on p j84] That means, the arguments of Program Max are checked by the 
respective precondition and the return- value finds is related to the input by the respective postcondition 
on termination of the program: 

01 Programi Max (givens::real list) (max::real) (finds::real list) (rels::bool list) 

02 (var::real) (interval: :real set) (errbound::real) = 

03 LET 

04 maxequ = Take ((ED o (FILTER ( contains max ))) rels) ; 

05 funtenn = (IF 1 < LEN rels 

06 THEN (Subproblem ( Reals, [make, diffable, function], makej^un) 

07 / max::real, var::real, rels::bool list, interval:: real set ] ) 

08 ELSE (ED rels )) ; 

09 max = Subproblem ( RealMgebra, [onJnterval, max, argument], 

10 maximum _onJnterval ) 

11 [ funterm::real, var::real, interval:: real set ] ; 

12 find-rels = FILTER_OUT ( ident maxequ) rels ; 

13 finds = Subproblem ( Reals, [tool, find _values], find _values) 

14 [ max::real, (WS funtenn):: real, var::real, max::real, 

15 find-rels::bool list, errbound::real ] 

16 IN finds 

In ISAC this program is parsed as an Isabelle term with LET.. IN, IF.. THEN.. ELSE from Isabelle/HOL 
extended by definitions for Program, for "tactics" like Take, Subproblem and for some functions 
LENgth (of a list), RHS (right-hand side of an equality), FILTER.OUT; some of these functions are al- 
ready contained in the recent Isabelle versions. The reader may note that the notion of "tactic" is being 
extended: Tactics have been introduced in Defj2]as parts of steps in calculations, in the above program 
certain statements are called "tactic" — those statements which generate the steps of the respective cal- 



culation. ^5.1 will unify the notions of tactics formally. 

The function's arguments are worth one more remark: For instance, the Subproblem at lines #09. .#1 1 
above takes two arguments, a triple and a list; the triple addresses three kinds of knowledge as mentioned 
above: 

1. deductive knowledge: RealJilgebra is an Isabelle theory comprising all the axioms, definitions 
and theorems required for the formulas of the generated calculation and for proving the postcon- 
dition of the calculation's specification. This is where the differentiation rules come from in the 



second example program on p 92 
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2. application-oriented knowledge: [onJnterval, max, argument] is a path into a hierarchy of speci- 
fications: the element retrieved from the hierarchy specifies the calculation to be generated. 

The specification is expected to be proved by ATP during interpretation: before the call the precon- 
dition is proved for the function's arguments, on return the postcondition is proved for arguments 
and return value. 

3. algorithmic knowledge: maximum onJnterval is a reference to the program describing the algo- 
rithm which creates the calculation. 



The second argument of the Subproblem contains some formal arguments funterm, var, interval as 
known from function definitions: 

[ f ante nn:: real, var::real, interval:: real set ] 

The list of arguments might contain more items than the respective specification — this becomes 
clear when considering the example program above which has these formal arguments: 

01 ProgrEim Max (givens::real list) (max::real) (finds::real list) (rels::bool list) 

02 (var::real) (interval: :real set) (errbound::real) = . . . 



The number of arguments is seven, although both respective specifications no.l and no. 2 on p 84 
only have one input, { r } for the first argument givens — the other arguments provide the input for all 
the Subproblem of the program! 

This program is the first of two examples for a "CTP-based programming language" (where the 
second example program is on pj92]below). A thorough introduction of such a language is out of scope 
in this paper, lUl gives further details and §6.3| discusses open questions. 

The reader may note, that the above programs are purely functional, thus do neither they contain 
input statements nor output statements, and thus cannot be concerned with interactiorj^ Interaction, 
however, is the key point of this paper and will be tackled subsequently. 



5 Deduction and Computation for User Guidance 

Now all prerequisites are prepared for introducing "Lucas-Interpretation": specifications of problems, 
calculations stepwise creating an explicit specification by applying tactics, calculations augmented by 
logical contexts, contexts containing facts required to check user input and to check the postcondition 
by ATP, a CTP-based programming language involving theories, specifications and programs, CAS- 
functionality included in this language. 

Now the idea of Lucas-Interpretation is simple: 

• The interpreter works like a debugger jumping from break-point to break-point in a program. 

• The breakpoints are the tactics in the program; each tactics generates exactly one step in the cal- 
culation (a step which might comprise an arbitrary number of sub-steps, which are not shown to 
the user — rather, the system is ready to show them on request of the user). 

• Each step also generates specific logical facts; the interpreter builds up contexts with these facts 
according to certain rules. 

'^The programmer of a CTP-based program is much concerned with theories, specifications and algorithms; so excluding 
concerns of interaction, of user guidance, etc. is a helpful separation of concerns. 
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• All steps are presented to the user on a "worksheet" (if not a dialog component decides for some 
other kind of interaction, for instance in a written exam). 

• After a step has been presented to the user, control is handed over to the user (to the dialog com- 
ponent, respectively). 

• Since the user is in control of the system, she or he has a variety of choices collected under four 
categories: 

- Inspect the calculation generated so far: ask for theorems applied at certain steps, ask for 
intermediate steps for instance in Rewrite_Set simplifier, etc. 

- Investigate the underlying knowledge in theory, specification or program: inspection starts at 
the particular knowledge item used in the current step. 

- Input an own step independently, a formula or a tactic (or something else according to the 
dialog component, for instance, a partial formula presented for filling in just some (crucial) 
part). 

- If got stuck in the calculation ask the system to do the next step. This feature enables a dialog 
component to provide user guidance; dialog details are out of scope of this paper; see |[T5l . 

• User input is checked by ATP, which is called by the interpreter using facts collected in the context. 
Feedback from ATP goes to the user (probably filtered by the dialog component). 

• After input the interpreter resumes execution, probably at another location in the program due to 
free user input. 

The subsequent sections describe first how the interpreter jumps from break-point to break-point, then 
how logical context are built up during interpretation and finally how user guidance is created automati- 
cally. 

5.1 Steps of Interpretation Create Steps of Calculation 

Steps of calculation (Def|2]l comprise tactics as parts which give a denotative name to the step; within 
programs those statements are called (program) tactics which create a step of the respective calcula- 
tion. Programs comprise further statements, which do not create steps; these are called non-generating 
statements. 

Since Program Majc contains only one non-generating statement in line #12, we give another exam- 
ple: a program calculating the derivative of a function and making the specification on p{89|expUcit: 

01 Progrgmi Differentiate (interval: :real set) (f::real) (v::real) = 



02 LET/' = Take fj^/) 

03 IN (REPEAT 

04 ( Rewrite_Inst [(bdv, v)] diffsum ) OR 

05 ( Rewrite_Inst [(bdv, v)] diff-product ) OR 

06 ( Rewrite_Inst [(bdv, v)] diff^in ) OR 

07 ( Rewrite_Inst [(bdv, v)] diffjoos ) OR 

08 ( Rewrite_Inst [(bdv, v)] ) OR 

09 ( Rewrite_Inst [(bdv, v)] diffjraction )) 00 

10 ( TRY fRewrite_Set simplifier )) f 



Again, the syntax of this kind of program is discussed in detail in |[8l, here are the hints for reading 
the program text: After constructing the formula from the program's arguments in line #02 the body 
of LET. . IN forward chaines (m) two functions, REPEAT(. . .) and TRY (Rewrite_Set simplifier). The 
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former models the non-deterministic behavior of term rewriting systems: the rules diff^in OR dijfjcos OR 
. . or other rules can apply or not, and as soon none applies REPEAT terminates. The latter function 
TRYs to simplify the resulting formula. 



The lines #08-#13 in the example calculation on p 85 could have been generated by this program. 
Let us assume this calculation has been continued as follows: 



11 = 8 • • (sina • j^cosa + sina) • cosa) — 4 • -2 • sina • ^ sina 



• ■ (sin a ■ cos a + cos a ■ cos a) — 4 • • 2 • sin a • sin a 



Rewrite ^(sina) =cosa #06 



Rewrite -^(cosa) = -sina #07 



da 

= 8 • • (sina • (— sina) +cos a • cos a) — 4 • • 2 • sina • ^ sina 

Rewrite ^(sina) =cosa ??? 

First line #06 of the program has been interpreted (indicated by the line number at the right margin 
above), then the subsequent line #07. Finally line #06 with the rule dijf_sin should be interpreted again in 
order to derive ^ sin a — how does the interpreter come back to the respective location in the program? 

Starting from location #07, this is accomplished by the sequence of statements 

^Q'~J ^OR ^Rewrite dijf _fraction ^REPEAT :^Q^ ^Rewrite dijf _sum 

#04 ^™ #05 -^R^^-^ite dijf product 
#05 ^™ #06 ^M^in 

The statements OR, REPEAT (and also LET . . IN, 00, Try) are concerned with controlling the sequence 
of interpretation and are called tacticals; they do not change the calculation or the respective context. 
ISAC's interpreter controls such sequences by locations in the program and by environments as usual. 

The above example leads to the following definition in a straight forward manner, just adding a 
program-state to Defj2]for steps of calculation: 

Definition 5 (Step of interpretation) Given a specification s = {I,p{I),0, _, _), a program m and a re- 
spective program-state y, given non-generating statements s„g and a (program)tactic t^ both in m, given 
an (intemal)tactic tc according to DeJ^ a context x and a sequence of formulas F, then a step is an 
application of the rule 

7 / y" t,n^t t applied Jo {x,F) = {x' ,F') 



Y,x,F Y',x',F' 

where tm ~ fc denotes equivalency induced by a bijective mapping between program tactics and tactics 
in calculations — due to this equivalency the distinction is omitted in the rule 's conclusion and the tactic 
named t. 

The initial configuration for applying the rule is Yq,xq,Fq with /o = (0, {(/i,vi), . . . , (/«, v„)}) where 
is the location at the root of program m and {ii,Vi) are the identifier-value pairs of the arguments ofm, 
and xo,Fo are as defined in Def^ We say 'the steps are initialized Jby s,m'. 

Interpretation stops at the first applicable tactic found after passing non-generating statements Sng, which 
are either tacticals or expressions containing no tactic. A subsequent step is triggered from outside 
without caring about program tactics, so we introduce a judgement do Jiext generalizing over all tactics t 

r,x,F^'y,x',F' 

— — — dOJieXt 

Y,X,F ^do_next y^x'^F' 

A detailed description of the tacticals' semantics is out of scope of this paper. We just note, that the 
example program on pj92] would raise an error in line #10 if the tactical TRY would be omitted and the 
tactic Rewrite_Set simplifier would be not applicable. 



^In order to come traditional notation as close as possible, the type of the function term is real and not real => real; so we 
need to instantiate bdv by the actual value of v in the rules before rewriting. 
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5.2 Building up Logical Context during Interpretation 

Contexts are required to check user input by ATP during interpretation, to check preconditions and 



post-conditions of Subproblems and finally check the solution of a problem ({ 3.2 1 by ATP as well. How 



contexts are used to accomplish these tasks is introduced in ^ 5.3 



How logical contexts Xi are built up during execution can be observed in the running example as 



follows (the numbers on the left refer to those in program on p 90 1: 

: { < r } UX^,pgj(ryl „ UX,hy 

: xo U { A — 2uv — u^} 

-xi U { A(a) = 8 • • sina - cosa — 4 - • (sina)^), 
A{a) is jiifferentiable _on ]0, |[ } 
U { A' (a) ~S-r^ ■ (-(sina)^) + (cosa)^ — 2 • sina -cosa), 
a = tan-'(-l+\/2), A'(a)=0, 
Va'. a' e ]0, f [ AA;X«') = 0^=^ a' = (tan-i(-l + V2)) 
ya'.a' e ]0,{[^A{a')<A{a)} 
: X3 U {m = 2 • r • sina, m w 0.23 ■ r, v = 2 • r • cosa, u « 0.76 • r } 

The initial values in xq comprise the precondition and < r, the type constraints for the input vari- 
ables / and the output variables O of the specification as well as all required knowledge collected in 
theory thy. 

The facts added in lines #09. .#12 to context X2 deserves explanation: the first line (a) is the result 



01. 
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XQ 
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.04 


Xl 


05. 


.08 


X2 


09. 
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X3 
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X4 



of Suh-Prol)lem[differentiate, function] (see calculation on pl851 specification on p 89 and program on 



p 92i. The second and third line (b,c) come from Problem [onJnterval, goniometric, equation]: the 
latter is the postcondition stating that the equation has exactly one solution within the interval given. 
A single solution is required for this type of problem at this place, and it is the responsibility of the 
math author to prepare a specification with an appropriate interval. Line (d) is the postcondition of 



Subproblem [onJnterval, goniometric, equation] on p 85 

The reader may note that contexts do not follow the scoping rules for program variables (which en- 
close variables within subprograms): Problem ( Reals, [onJnterval, max, argument] exports the values 
and the post-conditions of the respective sub-problems (lines (b,c)), Problemf differentiate, function ] and 
Problem [onJnterval, goniometric, equation[. The scoping rules for contexts are a consequence of the 
common practice to have unique variable names within a calculation. 

Although there is (still) no implementation of proofs for postconditions in IS AC, there is the convic- 
tion that the final context X4 contains sufficient facts for such proofs. 

5.3 Lucas-Interpretation Combines Computation and Deduction 



A Lucas-Interpreter stepwise executes a CTP-based program {{ 4.2 ) and creates calculations (Def j3]l step 



by step (Def j2]). In order to integrate these concepts, the following definition is close to Defj3j Def j2] and 
Def|4| actually the only additions are a program and a program state: 

Definition 6 (Lucas-Interpreter) Given a specification s, a calculation c = (X, ^(F),r, — )-,S) and a 
program m, then a labeled terminal transition system ^ = (E, Tm,^m,S,n) is called a Lucas-Interpreter 
iff 

(i) the configuration S = (F x X x ^(F)) contains T the program states (Dej^ and X x .'^{F) the 
configurations in c (Def^ 

(ii) the actions T,„ contain (program) tactics in m and is bijectively mapped with T 
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(in) the transition relations — t-'"' are steps of interpretation according to Dej^with YjX,F —)•'"' y,x',F' 
and are itinitializedJby s,m. 

(vi) the terminal configuarions Sm C (r,„ x X x ^(F)) contain T,„ the terminating states ofm. 

We say c is generated J)y (s,m,^). 

The bijective mapping between T and 7]„ continues the bijective mapping between external tactics and 
internal tactics from pjST} again further distinction seems not necessary and we write t instead t^ in the 
sequel. 

The steps of interpretation in the above definition are triggered by the user requesting dojiext ac- 
cording to Defj5] Instead of dojiext the user also could have input a step of his or her own choice; 
after such input dojiext raises the usual issue for debuggers: in which cases can execution (in our case: 
interpretation) resume, and in which cases it cannot resume due to too invasive operations at the break- 
point. A step can be given by two classes of input, which might be modified and combined by a dialog 
component, see 1,15.1 . The first class is characterized by input of an (external) tactic, the second by input 
of a formula: 

Input of a tactic is done by the learner at steps where the theorem to be applied is the point (e.g. a 
rewrite rule applied to a huge term too laborious for input), where some sub-term needs to be picked 
out for the next step, where a sub problem has to be started, or other cases, where the learner prefers to 
input a tactic instead of a formula (or the dialog component decides according to some rule in the dialog 
mode). The following definition describes how Lucas-Interpretation handles the input (external) tactic 
ti: 

Definition 7 (Locatable tactics) Given a specification s, a program m, a Lucas-Interpreter ^ — 
-^m,Sm) cit configuration X = ij^^^F) £ S, a calculation c with c is .generated Jjy {s,m,^) at configu- 
ration x,F and finally given an (external) tactic tj input by the learner, then we have the rule 

ti applied Jo {x,F) = (x',F') 7,x,F ^* /,x,F Y',x',F' tj ^ t^ 

Y,x,F Y',x',F' 

If the rule is applicable (in particular if for ti an equivalent t,,, in the program is found, ti ~ tm), we say 
't is Jocatable Jit % ' iff applicable; otherwise we say is Jielpless Jit X- 

The definition's rule has tj applied Jo {x,F) as premise: if this premise is given, we get a step of calcu- 
lation leading to x' ,F' , but if no tj ^ t,„ is found during interpretation, we don't get a a program state 
to resume interpretation form — is helpless. 

Note that the transitions — searching for tj t„, only change the program state 7 and not the 
configuration x,F of the calculation; so x' ,F' resulting from tj is presented to the user, before control is 
handed over. This behavior is consistent with transitions being functions and not relations in both defi- 
nitions, in calculations (Def|3]l as well as in Lucas-Interpretation (Def j6]). And the strategy implemented 
by Def |7] works particularly well with programs like the example on pj92] 

If a t,„ with tj tm cannot be found, the step of calculation can still be done (according to 
ti applied Jo {x,F)) — but no appropriate tactic could be found in the program, thus the Lucas-Interpreter 
cannot determine a next step and "is helpless". Since this case easily can happen (for instance, if a 
"creative" rewrite rule is applied which cannot be found in the program), there is a stronger feature of 
Lucas-Interpretation for input of formulas. 
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Input of a formula concerns the second class of input for a learner constructing a calculation. Since 
user interfaces are expected to support copy-and-paste, input need not be laborious even for huge formu- 
las. The following definition describes how Lucas-Interpretation handles an input formula //: 

Definition 8 (Derivable formula) Given a specification s, a program m, a Lucas-Interpreter ^ = (S, 7^ 
-^m,Sm), a calculation c with c is ^eneratedJjy {s,m,^) at configuration x,F and finally given a for- 
mula fi input by the learner, then we have the rule 

Y,x,F -^'* Y,x',Fi 

If the rule is applicable we say 'fi is_derived_from '; otherwise we say 'fi is_not_derivable_from 

In this case the interpreter executes the next tactics found in program m until a context x' is generated, 
which can justify the input //, i.e. c hy //. This justification might involve algebraic simplification as 
mentioned in ^ If successful, the step is presented to the user, before control is handed over; t* is a 
tactic called "ad-hoc derivation"; it usually comprises a sequence of tactics. 

If not successful, i.e. the interpreter executes program m until termination and no step is found with 
c l~jc' //> then // is "not derivable". This judgment can be costly in resources, since it relies on an (internal) 
computation of the program, including all the subprograms, until termination. 



6 Related Work and Open Questions 

6.1 Proofs, Structured Derivations and Calculations 

As mentioned above, educational systems shall be "systems which do not make mistakes", so well- 
designed logical foundations are indispensable. 



Proof languages like Isar fT]\ are natural to compare with the approach taken in this paper, since the 
underlying prototype is based on the CTP Isabelle [26 1. Unlike the proof languages 

ofCoq[10|,Ltac[3 

and SSReflect [6], Isar is self-contained and does not refer to a proof state explicitly. 

The requirement to be "as close to what is written to traditional blackboards as possible" inhibited the 
above calculations to follow the principle of being self-contained. Rather, calculations rely on internal 
contexts employed in all definitions. This is the price for high usability for the target group. The price 
is considered not too high, since contexts consist of formulas in predicate logic and thus can easily be 
presented to the user, as soon as the user requests for them (and then they can be filtered by a dialog 
component). 

Isar specifically supports calculational proof fSTl and integrates it well with other elements of the 
proof language. Nevertheless, the formalisms were considered too far from "what is written on traditional 
blackboards" for our target group. 



Structured derivations (SD) f?] continue work on calculational proof fS", "7^, provide foundations on 
natural deduction, are self-contained such that they need not refer to a state separate from the SD and 
also are "close to what is written on blackboards". 

So, SD meet essential requirements for mechanized calculation and call for justification of any other 
choice of format. Major parts of the example calculation on pj85] exactly model SD, for instance lines 



^"httpV/coq .inria.fr/stdlib/Coq. Program. Tactics.html 
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#08. .#13. The sub-Problems strengthen the rigor by requiring explicit formal specification (which might 
be hidden from the learner and done automatically behind the scenes). And the rigor of SD is weakened 
by allowing to omit the tactics (at the right margin on p 85 1. The weakened rigor allows to address a 
wider range of users, who need no prior introduction to the system — "next step guidance" provides per- 
fect ad-hoc introduction. Another point is, that SD concerning sub-terms of formulas involve "window 
inferencing" |[T9l . which is already more complicated. 

For these reasons a format more general than SD has been implemented in ISAC. 



6.2 "Correctness" in Lucas-Interpretation 

This subsection doesn't address related work, only open questions on "correctness". Correctness of cal- 
culations is indispensable for an educational "system which never makes mistakes" llT2i . Final correct- 
ness of a calculation is given by Def j4} the solution meets the postcondition. The steps (tactic/formula) 
of calculation constructing such a solution are either input by the user or determined by a program under 
Lucas-Interpretation. An input tactic is checked if it is _applicable Jn the calculation (Def j2]) - this im- 
plies "correctness". An input formula is proven derivable (Def j8]l or not, thus it is "correct" or not. Both 
notions of "correctness", however, cannot exclude steps which are "misleading" to somewhere and not 
to a solution. But if the user relies on the system and requests dojiext (Def|5]l, the system shall guarantee 
to come to a solution finally: 



Definition 9 (Correctness under Lucas-Interpretation) Given a specification s, a program m, a Lucas- 
Interpreter ^ = (S,r,„,— a calculation c with c is ^generatedJby {s,m,^) and a sequence of 
steps of interpretation triggered by dojiext Xo -^'^"-^'^^^ . . . -^do^next _ (y^jX„,F„). Then c is correct 
under s,m,^ iff 

Xn £ Sm=^ c is. completed -With {x„,Fn) 



This definition says: if Lucas-Interpretation terminates, the generated calculation provides a solution 
{xn,Fn). So we only have a definition of correctness, but we want to have a proof! The definition 
describes the general proof obligation for the programmer of m and s. In order to actually verify m with 
respect to s a rigorous formal semantics for each tactic t will be required: such a semantics just would 
have to add specific properties of t to Defj2](which then would carry over to Defj5]l. This theoretical work 
seems most promising if combined with RTD of a development environment which integrates specific 
verification tools: a CTP-based IDE for a CTP-based programming language. 

ISAC already shows the advantageous consequences of the above definition: the learner, if got stuck 
after some trials, always can backtrack to a step where reaching a solution is guaranteed — this feature 
allows interactive learning known from chess programs: when reaching a disadvantageous chess con- 
figuration just backtrack to another configuration and start a new trial (a novel kind of interaction for 
EMAs). Experience with the prototype shows, that learners get used to find out the position where to 
back-track very quickly. 

The open questions above on correctness have already raised vague ideas, that the components in- 
volved in Lucas-Interpretation are related by refinements [3]. The components are specification, calcu- 
lation, problem-class and program (where problem-class has not yet been discussed): 
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(1.) 


specification C 


calculation 






□ 


(2.) 


problemclass C 


program 




t (3.) 


t (4.) 



A look at the above refinement relations (C) gives the following big picture: 

1. specification C calculation seems clear to a mathematician; however, the underlying definitions 
(Def j2} Defj3]and DefQ might be not strong enough for describing this refinement. 

2. problemclass C program involves a notion not introduced here because not yet clarified: "problem- 
class" would be some "specification-pattern" which allows to mechanically generate a specifica- 
tion of the program from the input 'props': see example specifications no.l and no.2 and imagine 
all the other examples belonging to the problemclass "Extremwert Aufgaben" (which is claimed 
to be solved by one and the same program, the example program) — how would a specification 
(-pattern), as general as the program, would look like? 

3. problemclass C specification is expected to help clarifying the question from the previous Ptj2] 

4. program C calculation is the crucial point addressed by Def |9) 



6.3 On CTP-based Programming Languages 

Lucas-Interpretation takes a certain kind of "CTP-based programming language" as a prerequisite, which 
only exists in ISAC under consideration. However, ||8l argue for a value of their own for such languages 
and identify interest for CTP-based languages: For CAS -based programming languages great demand 
appears in successful application to software for engineering and science, most of which use CAS-based 
languages like |[T] |20l as an efficient base for development — while lacking reliability of CAS is widely 
recognized, see for instance ||9l; so one may expect developments meeting the demand indicated by the 
success of CAS-based languages with more reliable CTP-based languages. 

Significant preparatory work |13, 14| for CAS-like functionality in a CTP framework has already 
been done. In the course of eventual development of CTP-based languages several further issues left 



open by CAS might be tackled: Reliable handling of partiality conditions has been mentioned in {4.1 
Multivaluedness is another issue [1 1 1. Very appealing for educational purposes would be to calculate ex- 
act approximation given by floating-point numbers (see [27 1 for Coq) throughout all algebraic operations 
involved in a calculation; already |9| has laid the grounds for tackling this issue. 

Using CTP-based programs not only for implementation of applications like the running example 
(pj90|, but also for the CAS-functions themselves will lead to "systems that explain themselves" at an 
extreme level: For instance, cancellation of multivariate polynomials hke 

x^-y^ {x + y)-{x-y) x+y . 

-T, = -. r — = assummgxf^UAx — yf^U 

x^—x-y x-\x—y) x 

is a frequent task already in early years of math education; usually it is explained "from right to left". 
But a smart student might ask, how a machine accomplishes the task from left to right (by factoriza- 
tion, by Hensel lifting or the like). If factorization or Hensel lifting is programmed in a CTP-based 
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language and interpreted by a Lucas-Interpreter, then such a student gets stepwise user guidance through 
the comprehensive algorithms on request: 

With a CTP-based language and Lucas-Interpretation "implementation of tutoring becomes a side- 
effect of programming", see Figj2]on p 89 



With that in mind interesting questions arise when re-implementing CAS-functions: CAS-algorithms 
at the state-of-the-art are high-brow in general (not only in the above case, also in integration, solving 
equational systems etc.). In order to foster students' curiosity and do not bother them upon questions 
of "how is that done", the possibility to select between high-brow algorithms and elementary algorithms 
(the latter probably not able to solve a certain problem) is already implemented in ISAC. 



7 Summary and Conclusions 

This paper presented an innovation in base technology for educational math assistants which is mainly 
motivated by pedagogical requirements. So we finish with a summary of technology and a conclusion 
concerning pedagogy. 

A Summary of Lucas-Interpretation states a novel base technology for automatic generation of user 
guidance in stepwise solving problems in engineering and in applied science: Given a program written 
in a novel kind of CTP-based programming language which solves a problem, Lucas-Interpretation gen- 
erates steps (Def j2] Def j5]l of a calculation (Def j3]l as a side-effect (Figj2] on p j89]) of the (functional) 
program. During stepwise interpretation a logical context is built up in order to provide ATP tools with 
the facts required for proving derivability of user input. At each tactic in the program control is handed 
over to the user (Defj6]l. The user is free to investigate the underlying knowledge, to freely input a step 
independently (checked by ATP immediately) or to ask the system to propose a next step (DefjTJ Def J8]) 

According to the novelty of the design essential questions have been left open and are addressed in 
a separate section: In particular, the main theorems of Lucas-Interpretation are not proved due to the 
lack of a formalized operational semantics: The solution of a calculation is correct if the user does not 
interfere by other input than requesting the next step (Def j9]l and interpretation can guarantee to resume 
after user input provided certain constraints on the input. 

Although still a prototype, the Lucas-Interpreter has already established a stable interface to a dialog 
component, ready for experts in learning theory to start with detailed design of interaction in stepwise 
problem solving — this task is rigorously separated from extending the math topics of the problems: 
each problem just requires to program the algorithm solving the problem, interaction is handled by 
Lucas-Interpretation. 

Conclusions for pedagogy expect impact on math education: CTP-technology allows to relate formal 
facts and activities in stepwise problem solving mechanically within the system. This is a considerable 
advantage over CAS or DGS (Dynamic Geometry Systems), where specific steps (integration, equation 
solving, etc.) are accomplished by the systems, well, but the whole process of stepwise problem solving, 
the relation between input (precondition), output (postcondition) and intermediate steps are left to the 
programmer media designer, who is overwhelmed by hard-coding feedback for the variants of steps. 

On the other hand, CTP-based software models all mechanical parts of problem solving and thus 
allows to mechanically generate feedback to the learner: ATP ensures both, the most reliable and the most 
general checks of user input. This extends the scope of EM As far beyond CAS or DGS. So upcoming 
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CTP-based educational math assistants will be novel and powerful tools for patient and reliable feedback 
in exercising and assessing stepwise problem solving. 

If, in addition, educational math assistants want to go in line with renewed science education ||29]| 
and decisively support inquiry-based learning and independent learning, then "next step guidance" is 
required: students can explore new topics, tackle motivating problems and interactively try out solutions 
passing new stuff by help of the system, students can try variants in calculations and ask for the next step 
if got stuck — the latter is the unique feature Lucas-Interpretation contributes as a base technology for 
educational math assistants. 
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